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NOTICE 


;login: is the official newsletter of the 
USENIX Association, and is sent free of charge 
to all members of the Association. 

The USENIX Association is a not-for-profit 
organization of those interested in UNIX and 
UNIX-like systems. It is dedicated to fostering 
and communicating the development of 
research and technological information and 
ideas pertaining to advanced computing 
systems, to the monitoring and encouragement 
of continuing innovation in advanced comput¬ 
ing environments, and to the provision of a 
forum where technical issues are aired and 
critical thought exercised so that its members 
can remain current and vital. 
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Contributions Solicited 

Members of the UNIX community are 
encouraged to contribute articles to ;login:. 
Contributions may be sent electronically to 
login@usenix.org or through the U.S. mail to 
the Association office. The USENIX Associa¬ 
tion reserves the right to edit submitted 
material. 

.login: is produced on UNIX systems using 
troff and a variation of the -me macros. Con¬ 
tributions should be in n/troff input format, 
using any macro package. 
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Call for Papers 

Winter 1990 USENIX Conference 

January 22-26, 1990 
Omni Shoreham 
Washington, DC 


Papers are sought in all areas of UNIX- 
related research and development for the tech¬ 
nical program of the 1990 Winter USENIX 
Conference. Papers which are accepted for the 
conference will be published in the conference 
proceedings and shall be presented during the 
three days of technical sessions at the confer¬ 
ence. 

Appropriate topics for presentation 
include, but are not limited to: 

New Tools and “Little Languages” 

UNIX and AI: 

Intelligent Systems 
Neural Nets 
Ada and UNIX - 

Real Experience and Future Expectations 
File Systems and Servers 

Failsafe and Failsoft File Managers 
Hierarchical File Migration 
Version Control 
Architectures and Compilers 
Software Release Systems and Servers 
Documentation issues 
Distributed Systems and Services 
Networking and Security 
User Interfaces and 

User Interface Management Systems 
Experiences and Novel Applications 

All submissions will be considered - how¬ 
ever, papers detailing new and interesting 
work will be regarded much more favorably 
than thinly disguised product announcements 
or re-runs of previous reports. The Winter 
1990 conference is requiring that extended 
abstracts (and not full papers, as in previous 
conferences) be submitted. An extended 
abstract should describe the nature of the 
work, summary of results and conclusions, and 
should be between 1000-2000 words long (two 
to three typeset pages). Time is scheduled for 
authors of accepted papers to complete their 


submissions; therefore, extended abstracts will 
only be accepted when it is felt that a complete 
and worthy paper can be produced by the final 
due date. 

The final paper should include a 100-300 
word abstract, a discussion of how the paper 
relates to other work, illustrative figures (where 
appropriate), and citations to relevant litera¬ 
ture. Only previously unpublished submis¬ 
sions will be considered. Final papers should 
contain on the order of 8-12 pages of single 
spaced typeset materials. All final papers must 
be submitted in a camera-ready format or elec¬ 
tronic format (troff -ms if possible) - 
typewritten or dot-matrix output is not accept¬ 
able as final output. For authors without 
access to a laser printer or typesetter, 
appropriate facilities will be provided by the 
program chair. 

Please submit abstracts as soon as possi¬ 
ble, and mail one hard-copy and one 
electronic-copy to the addresses below. The 
final deadline for receipt of submissions is 
August 14, 1989; abstracts received after this 
deadline will not be considered. Notification 
of acceptance or rejection will be made by 
September 25, 1989. Final camera-ready 

papers are due by November 17, 1989. 

To submit a paper or request additional 
information, please contact: 

Daniel V. Klein 

Washington USENIX Technical Program 
Software Engineering Institute 
Carnegie Mellon University 
Pittsburgh, PA 15213 

+ 1 (412) 268-7791 (work) 

+ 1 (412) 422-0285 (home) 

+ 1 (412) 268-5758 (FAX) 

wash-usenix@sei.cmu.edu 

uunet!sei.cmu.edu!wash-usenix 
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Large Installation Systems Administration III 
Workshop and Tutorial Program 

September 6-8, 1989, Marriott Hotel, Austin, TX 
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In light of two successful workshops on Large Installation Systems, there is a demonstr¬ 
able benefit in bringing together system administrators of sites with 100 or more users (on 
one or more processors) to compare notes on solutions to a variety of common problems. 

Tutorials - Wednesday, September 6 

A two-track tutorial program will be offered in conjunction with the workshop. Atten¬ 
dees will be able to change between tracks at each topic change. The tutorial notes will 
include material from both tracks. The tutorials will be presented by Rob Kolstad of 
Prisma, Inc., and Evi Nemeth and Trent Hein of the University of Colorado. 

Joint discussion of ethics, privacy, and security in centralized and distributed systems 
Management policies Internet networking 

Security NFS/YP 

Large scale backups UUCP 

Machine Room Organization NeWS 

Performance sendmail 

User ID management System upgrades/local documentation 

Joint wrap-up discussion: Public Domain Software, Miscellaneous Topics 

Tentative Technical Program 

Thursday, September 7 

Introductory Remarks 
Keynote Address 

Networked Heterogeneous Systems I 
Accounting 

Network Administration 
Birds of a Feather Sessions 

Friday, September 8 

Networked Heterogeneous Systems II 
Panel: Distributed Services 
Work in Progress 
Security 
Backup 


Alix Vasilatos, Program Chair 

Paul Graham, Chair 
Bjorn Satdeva, Chair 
Kevin Smallwood, Chair 


Bjorn Satdeva, Chair 

Paul Graham, Chair 
Alix Vasilatos, Chair 
Kevin Smallwood, Chair 


The registration fees are $225 for the tutorial and $200 for the technical sessions. You 
may register for only the tutorial class, only the technical sessions, or both. The registration 
deadline is August 30, 1989. For registration and hotel information, please call the USENIX 
Conference Office at (714) 588-8649. 
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Workshop on Experiences with 
Distributed and Multiprocessor Systems^ 

October 5-6, 1989, Marriott Hotel, Ft. Lauderdale, FL 

The goal of this workshop is to bring together individuals who have built, are building, or will 
soon build distributed and multiprocessor systems, especially operating systems. The workshop will 
feature full presentations and work-in-progress presentations on aspects of building and using these 
systems. The workshop will provide a forum for individuals to exchange information on their experi¬ 
ences, both good and bad, in designing, building, and testing their systems. This includes experiences 
with coding aids, languages, distributed debugging tools, prototyping, reuse of existing software, per¬ 
formance analysis, and lessons learned from use of such systems. 

Tentative Schedule 

Thursday, Oct. 5 

8:30 Opening remarks. George Leach, Workshop Chair 

8:45 Session I: Objects and Virtual Memory 

A Distributed Implementation of the Shared Data-Object Model by Henri E. Bal, M. Frans 
Kaashoek and Andrew S. Tanenbaum (Vrije Universiteit, Amsterdam) 

An Implementation of Distributed Shared Memory by Umakishore Ramachandran and M. 
Yousef A. Khalidi (Georgia Institute of Technology, Atlanta) 

An Object-Oriented Implementation of Distributed Virtual Memory by Gary M. Johnston and 
R. H. Campbell (University of Illinois at Urbana-Champaign) 

10:45 Session II: Process Control 

Experience with Process Migration in Sprite by Fred Douglis (University of California, Berke¬ 
ley) 

Dynamic Server Squads in Yackos by Debra Hensgen and Raphael Finkel (University of Ken¬ 
tucky, Lexington) 

Fine-Grain Scheduling by Henry Massalin and Calton Pu (Columbia University, New York) 

1:30 Session III: Performance Considerations 

The Parallelization of Mach/4.3BSD: Design Philosophy and Performance Analysis by Joseph 
Boykin and Alan Langerman (Encore Computer Corporation, Marlborough) 

Efficient Implementation of Modularity in RAID by Charles Koelbel, Fady Lamaa, and Bharat 
Bhargava (Purdue University, West Lafayette) 

Making libc Suitable for use by Parallel Programs by Julie Kucera (Convex Computer Cor¬ 
poration, Richardson) 

3:30 Session IV: Concepts 

Revolution 89 -or- Distributing UNIX Brings it Back to its Original Virtues by Francois 
Armand, Michel Gien, Frederic Herrmann, and Marc Rozier (Chorus Systems, En Yvelines) 


t Sponsored by the USENIX Association and the Software Engineering Research Center (SERC), in cooperation with ACM 
SIGOPS and ACM SIGSOFT, and with the IEEE-CS TC on OS and IEEE-CS TC on Distributed Systems. 


July/August 1989 


5 



;login: 14:4 


A Network File System Supporting Stashing by Luis L. Cova, Rafael Alonso, and Daniel Bar¬ 
bara (Princeton University) 

4:20 Work-in-Progress presentations. 

Friday, Oct. 6 

8:30 Session V: Multiprocessors 

TUMULT-64: a real-time multi-processor system by Pierre G. Jansen and Gerard J. M. Smit 
(University of Twente, Enschede) 

Experiences with a Family of Multiprocessor Real-Time Operating Systems by Prabha 
Gopinath and Thomas Bihari (Philips Laboratories, Briarcliff Manor) 

Implementation Issues for the Psyche Multiprocessor Operating System by Michael L. Scott, 
Thomas J. LeBlanc, and Brian D. Marsh (University of Rochester) 

10:30 Session VI: Tools 

Experience with P/Mothra: A Tool for Mutation Based Testing on A Hypercube by ByoungJu 
Choi and Aditya P. Mathur (Purdue University, West Lafayette) 

Debugging and Performance Monitoring in HPC/VORX by Howard P. Katseff (AT&T Bell 
Laboratories, Holmdel) 

CAPS - A Coding Aid used with the PASM Parallel Processing System by James E. Lumpp, Jr., 
Samuel A. Fineberg, Wayne G. Nation, Thomas L. Casavant, Edward C. Bronson, Howard J. 
Siegel, Perre H. Pero, Thomas Schwederski, and Dan C. Marinescu (Purdue University, West 
Lafayette) 

The Implementation of Aide: A Support Environment for Distributed Object-Oriented Systems 
by Rodger Lea and Johnathan Walpole (University of Lancaster, Bailrigg) 

1:30 Session VI: Object-oriented Construction 

Experience With Implementing and Using An Object-Oriented, Distributed System by D. 
Decouchant, M. Riveill, C. Horn, and E. Finn (Bull-IMAG, Gieres) 

Prototyping a distributed object-oriented OS on UNIX by Marc Shapiro (INRIA, Le Chesnay) 

Clouds: Experiences in Building an Object Based Distributed Operating System by Umak- 
ishore Ramachandran, Sathis Menon, Richard J. LeBlanc, M. Yousef A. Khalidi, Phillip W. 
Hutto, Partha Dasgupta, Jose M. Bernabeu-Auban, William F. Appelbe, and Mustaque 
Ahamad (Georgia Institute of Technology, Atlanta) 

3:30 Session VII: Communications, Heterogeneous Systems, and the A-word 

Experiences with Efficient Interprocess Communication in Dune by Marc F. Pucci and James 
Alberi (Bell Communications Research, Morristown) 

Using Transputer Networks to Accelerate Communication Protocols by Horst Schaaser 
(Hewlett-Packard Laboratories, Bristol) 

ARCADE: A Platform for Heterogeneous Distributed Operating Systems by David L. Cohn, 
William P. Delaney, and Karen M. Tracey (University of Notre Dame) 

A Decentralized Real-Time Operating System Supporting Distributed Execution of Ada Tasks 
by Roger K. Shults (Rockwell International-Collins Divisions, Cedar Rapids) 

For information on registration, contact the USENIX Conference Office. 
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5th USENIX Computer Graphics Workshop 

November 16-17,1989, Doubletree Hotel, Monterey, CA 


The theme of the 5th USENIX Computer 
Graphics Workshop is “personal graphics.” 
By this, we mean the use of computer graphics 
to aid, benefit, or amuse a single person. 
Generally, personal graphics applications are 
highly interactive, so that the user has a great 
deal of control over the result. Furthermore, 
the graphics is frequently not an end product, 
but is instead a communication medium 
between the user and computer. Examples of 
personal graphics might include desktop pub¬ 
lishing, data visualization programs (e.g., 
MacSpin), windowing systems, micro-world 
simulations (Kay’s vivarium?), and “perfor¬ 
mance” graphics (e.g., video weirdness). It 


probably does not include ray-tracing, yet 
another VLSI graphics chip, or fast rendering 
algorithms. A distinguishing feature is that the 
user is included as an integral part of the 
description of the system. One question that 
may be addressed by presentations in this 
workshop is “How are ‘ordinary people’ going 
to effectively use computer graphics in their 
daily lives?” 

A program will be available in August. 
The workshop chair is Spencer W. Thomas, 
EECS Department, University of Michigan. 

For information on registration, contact the 
USENIX Conference Office. 


Preliminary Call for Participation 
USENIX C++ ’90 

Tentatively in late-April 1990 in California 


C++ continues to show explosive growth 
as the object oriented implementation 
language of choice for production level work. 
The nearly-annual C++ conference is a haven 
for those who use the language, those who 
develop the language, and those who are 
interested in the language. The conference 
enables them to take a look at where C++ has 
been, where is it now, and where future 
developments should take it. 

The conference will consist of a day of 
tutorials and classes and two days of technical 
sessions. Papers are invited on all aspects of 
C++, from the development of compilers and 
preprocessors to case studies of projects which 
have used the language. Proposals for tutorials 
or classes on systems which make use of C++ 
or on the uses of C++ are also invited. 

Paper abstracts and tutorial proposals are 
due January 12, 1990. Abstracts should be no 


more than two pages, and should describe the 
work in sufficient detail to allow the referees to 
judge the merit of the work. Tutorial 
proposals should be no more than four pages 
in length, and should describe the content, 
purpose, and intended audience. Abstracts 
and tutorial proposals should be submitted 
either electronically (preferred) or in hardcopy; 
electronic submissions should be either plain 
text, n/troff, or Postscript. Notification of 
acceptance will be made by February 2, 1990; 
final papers in camera ready form must be 
received by March 9, 1990. Accepted papers 
which meet this deadline will be published in a 
conference proceedings. 

Abstracts and proposals should be sent to: 

Jim Waldo waldo@apollo.com 

Apollo Computer decvixlapollolwaldo 

330 Billerica Road 
Chelmsform, MA 01826 
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EUUG Autumn ’89 Conference and Exhibition 

September 18-22 1989 
Vienna, Austria 

The Autumn 1989 European UNIX systems User Group Technical Conference will 
include technical tutorials on Monday and Tuesday, followed by a three day conference and 
exhibition. Subject areas of the technical program will include such topics as security, fault 
tolerance, transaction processing, RISC architectures, and user interfaces. 

For more information on the conference and tutorial program, please contact: 


The Secretariat 

Tel: 

+44 763 73039 

EUUG 

FAX: 

+44 763 73255 

Owles Hall 

Buntingford Herts, SG9 9PL, UK 

Email: 

euug@inset.uucp 


Call for Papers 

EUUG Spring ’90 Conference 

April 23-27, 1990 
Munich, West Germany 

The EUUG invites papers from those wishing to present their work. Full papers or 
extended abstracts must be submitted. Suggested subject areas include, but are not limited 
to: 

Standards for UNIX Systems 
Internationalisation 
Object Oriented Development Tools 
Object Oriented Graphical Toolkits 
Object Oriented Languages 

Program Generators for Commercial Applications 
Network Administration 
Security Issues and Authentication Techniques 
Document Context Architectures 

Submission deadline: November 15, 1989 

Acceptance notification: December 15, 1989 

Final paper: February 10, 1990 

Full papers or extended abstracts must be submitted by post to the EUUG Secretariat 
(address above), and, if possible, in electronic form to euug-munic@cwi.nl. Notification of 
acceptance will be acknowledged by return post. 
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Call for Papers 
Convention UNIX 90 
March 26-30, 1990, Paris, France 


Convention UNIX 90, organized by the 
French Association of UNIX Users (AFUU) 
and the Bureau International de Relations 
Publiques, will have parallel technical, user, 
and product conferences, and an exhibition 
and tutorials. 

The technical conference will cover a wide 
range of technical topics. The user conference 
will stress users experiences, analyses, and 
strategies in dealing with UNIX. The product 
conference will have exhibitor presentations 
concerning existing or future products. Sub¬ 
missions are invited for each of the confer¬ 
ences. 

Submissions should include a title, 
author(s) and affiliation(s), a mention of the 


conference for which the submission is offered, 
and a one page abstract. Abstracts must be 
received by Oct. 15, 1989. Notification of 
papers selected will be made by Dec. 1, 1989. 
Full papers are due by Jan. 31,1990. 

Submissions should be made to: 

A.F.U.U. 

Attn: Secretariat de la Conference 

Convention UNIX 90 

11, Rue Carnot 

94270 Le Kremlin-Bicetre 

France 

(+33) (1) 46.70.95.90 
afuuconf@inria.inria.fr 


Baltimore Terminal Room 

Many of you who were at the Baltimore 
USENIX Conference used the Terminal Room 
located in the Hyatt Hotel. The statistics from 
the Xylogics Terminal Server showed an aver¬ 
age of 1,100,000 bytes received and 930,000 
bytes sent per hour of operation across the 
Internet SLIP link. Approximately 400 local 
and toll free number calls were made from the 
room during the week, and at least 87 Sun car¬ 
tridge tapes of GNU software were made. 

I would like to thank Telebit, Xylogics, 
AT&T, and OSF for providing equipment and 
funds; Judy DesHarnais, Mike Ballard, Cerafin 
Castillo, John Loverso, Van Jacobson, Len 
Tower, Edgar Merke, Evi Nemeth, Ed Gould, 
and Trent Hein for their assistance in getting 
the room organized; and all the volunteers 
who worked long hours so that the conference 
attendees would not miss any urgent informa¬ 
tion at their home sites. 

Sonya Neufer 
Terminal Room Coordinator 


And the winners are! 

Attendees at the USENIX Baltimore Exhi¬ 
bition who registered at the Apple Computer 
and/or IBM Corporation booths were eligible 
to win a computer. 

The winner of the Apple Macintosh IIxc 
system and four application software packages 
was Peter Lega from Digital Equipment Cor¬ 
poration. Richard Karpinski from the Univer¬ 
sity of California, San Francisco, won the fully 
configured IBM/RT Model 135. 

Informal Programming Chair 

The Association would like to thank Alix 
Vasilatos for being the Informal Programming 
Chair at Baltimore. For the Winter 1990 
Conference, Sonya Neufer has been appointed. 
In addition to her responsibilities as terminal 
room coordinator, Sonya will coordinate such 
activities as the opening night reception, orien¬ 
tation session, some BOFs, and overseeing the 
many other functions that are not part of the 
technical program. 
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Long-Term Calendar of UNIX Events* 


1989 Sep 6-8 
1989 Sep 12-13 
1989 Sep 18-22 
1989 Sep 19-22 
1989 Sep 25-29 
1989 Sep 27-29 
1989 Oct 5-6 
1989 Oct 16-20 
1989 Nov 1-3 
1989 Nov 6-10 
1989 Nov 9 
1989 Nov 9-10 
1989 Nov 16-17 
1989 Nov 24 
1989 Dec 5-6 
1989 Dec 8-9 


! Large Systems Admin. Workshop 
MALNIX 
EUUG 

ACM SIGCOMM 
GUUG 

Workstation Operating Systems 

Distributed Systems Workshop 

IEEE 1003 

UNIX Expo 

DECUS 

NLUUG 

14th JUS UNIX Symposium 
Graphics Workshop V 
AFUU 

JUS UNIX Fair 89 
Sinix 


Austin Marriott, Austin, TX 
Kuala Lampur, Malaysia 
Vienna, Austria 
Austin, TX 
Wiesbaden, Germany 
Pacific Grove, CA 

Marriott Marina, Ft. Lauderdale, FL 

Brussels, Belgium 

Javits Conv. Ctr., New York, NY 

Anaheim, CA 

The Netherlands 

Osaka, Japan 

DoubleTree Hotel, Monterey, CA 
Paris, France 
Tokyo, Japan 
Singapore 


1990 Jan 

UNIX in Government 

1990 Jan 22-26 

USENIX 

1990 Jan 23-26 

UniForum 

1990 Jan 29 

IEEE 1003 

1990 Mar 26-30 

AFUU 

1990 Spring 

* C++ Conference 

1990 Apr 

IEEE 1003 

1990 Apr 23-27 

EUUG 

1990 May 

UNIX 8x/etc 

1990 May 7-11 

DECUS 

1990 Jun 11-15 

USENIX 

1990 Sep 11-14 

AUUG Conference 

1990 Oct 22-26 

EUUG 


Ottawa, Ont. 

Omni Shoreham, Washington, DC 

Washington Hilton, Washington, DC 

New Orleans, LA 

Paris, France 

California 

Montreal, Que. 

Munich, Germany 
/usr/group/cdn; Toronto, Ont. 

New Orleans, LA 
Marriott Hotel, Anaheim, CA 
Southern Cross, Melbourne, Australia 
Nice, France 


1991 Jan 21-25 
1991 Jan 22-25 
1991 Feb 
1991 May 
1991 May 20-24 
1991 Jun 10-14 
1991 Sep 16-20 


USENIX 

UniForum 

UNIX in Government 

UNIX 8x/etc 

EUUG 

USENIX 

EUUG 


Grand Kempinski, Dallas, TX 
Infomart, Dallas, TX 
Ottawa, Ont. 

/usr/group/cdn; Toronto, Ont. 
Tromso, Norway 
Opryland, Nashville, TN 
Hungary 


1992 Jan 20-24 USENIX 

1992 Jan 21-24 UniForum 

1992 Spring EUUG 

1992 Jun 8-12 USENIX 


Hilton Square, San Francisco, CA 
Moscone Center, San Francisco, CA 
Jersey, UK 

Marriott, San Antonio, TX 


1993 Jan USENIX 

1993 Mar 2-4 UniForum 

1993 Jun 21-25 USENIX 


Town & Country, San Diego, CA 
Washington, DC 
Cincinnati, OH 


t Partly plagiarized from John S. Quarterman of TIC and Alain Williams of EUUG by EY. 
* USENIX Workshops 
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New Conference Sessions 

USENIX gatherings have grown from a 
small group of people exchanging tricks of the 
trade to conferences of over 2000 attending 
two days of tutorials and three days of refereed 
papers. The interests of attendees have 
expanded to encompass networking, system 
administration, programming languages and 
development environments, text processing, 
windowing systems, user interfaces, and turn¬ 
key applications. Over the years, USENIX has 
adapted to this expansion by adding BOFs, 
tutorials, a vendor exhibit, workshops, 
published proceedings, and the journal. 
What’s next? 

During the Women’s BOF at the San 
Diego USENIX conference, a suggestion was 
made to augment the existing conference for¬ 
mat to help bring people of matching skills 
and interests together. Beginning with its 
Winter ’90 conference, USENIX will introduce 
experimental parallel sessions to provide new 
and complementary forums of technical excel¬ 
lence. Attendees will be free to migrate 
between these new sessions and the traditional 
sessions at will. Suggestions for new sessions 
include: 

* the informal exchange of information on 
current practical problems, resulting battle 
scars and solutions 

• “short courses” about specific tools and 
tricks 

* panel sessions providing experienced 
volunteers to answer questions 

• survey talks to broaden the expertise of 
members 

Lori Grob and Eric Allman have volun¬ 
teered to do the initial organization of the new 
sessions at Washington and at the following 


* Like all speakers in the technical program, these will get 
free registration only. 


Summer conference in Anaheim. The early 
plans are modest: five free “short courses” 
spanning the three conference days, including: 

• Andrew Hume on make and regular 
expressions. 

• Eric Allman on C Style/Portability. 

♦ John Quarterman will discuss survival in 
a global network. 

* The traditional meta-talk on submitting 
and presenting papers will be moved into this 
series. 

Other possibilities include talks on intro¬ 
duction to parallel programming, on submit¬ 
ting and diagnosing problem reports, and on 
fundamental principles in UNIX. 

These new sessions are planned for before 
and after lunch on Wednesday and Thursday, 
and before lunch on Friday. The final 
schedule will be included in the regular confer¬ 
ence mailing. 

We fully expect this new session to evolve 
and hope to be guided by discussions at the 
upcoming sessions and continual feedback 
from members. If the new sessions succeed, 
we may continue them as an annual event. 
Please send any and all comments and contri¬ 
butions regarding possible speakers,* topics, 
and formats to 

newsessionS)usenix.org 

Please don’t bother us with offers of vendor 
presentations. 

Sharon Murrel 
Eric Allman 
Lori Grob 
Ellie Young 
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The FaceSaver Project 

The USENIX FaceSaver Project reappeared at the Summer Conference in Baltimore. This time it was set 
up in the vendor exhibit area, which gave us the room, power and cooling necessary to run a comfortable 
operation. In just three days we collected over 900 portraits, which have been sent to uunet. These have 
been added to, or replace some of the 2222 portraits already on file, bringing the total of “unique” faces to 
2957. They are available via automatic mail request or via ftp. In addition to names and E-mail addresses, 
most of these portraits may contain phone numbers, companies and street addresses as supplied by the 
attendees. 

I want to thank the USENIX Association for sponsoring and funding 
this project, Rick Adams and UUNET Communications Services, Inc. 
for providing over 82 Mb of on-line storage for the pictures as a 
service to the community, the QMS Corporation of Mobile, AL for 
providing a laser printer, and Bell Technologies (now a division of the 
Intel Corporation) of Fremont, CA for providing their 80386 System V 
Release 3 system. The latter two enabled us to run two portrait stations 
in parallel. 

We were all very pleased that Craig Schwartz was our photographer 
again; he was assisted by Kathryn Johnson. I am grateful to Vincent 
Cawley and Mary Salus for cheerfully staffing the data terminals and 
dealing with the release forms, and to B. Edward R., Sir Peter 
Langston, Dan Klein, Ken Arnold, Paul Kooros and Reidar Bornholdt 
for their generous help. I also want to thank John Donnelly and Judy 

DesHarnais for taking care of the 
arrangements with the convention center 
and hotel. 

As in the past, attendees could have their 
pictures taken and/or retaken at no 
charge. The care taken by Craig and 
Kathryn in getting attractive portraits 
clearly justified the extra time they spent 
with each person. Some of the faces were 
transferred via cartridge tape to the show 
network file server during the conference 


and were brought up on workstations at the Sun® booth; the serial 
interface board in the network file server wedged every time we tried to 
uucp the pictures over, preventing full database transfer during the show. 

I have deposited a revised C program for printing individual pictures, and 
a C program with an associated PostScript program for generating a page 
of labels from the portrait data with uunet , for all to use and enjoy. 


Lou Katz 

Saver of Lost Faces 




Mary W. Salus Vincent Cawley 



Kathryn Johnson & Craig Schwartz 
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Information on accessing the faces from uunet: 

Welcome to faceserver, a system for distribution of faces by electronic mail and other means. This text is 
the reply you’ll get to: 

mail uunet!faceserver <EOF 

help 

EOF 

To examine the full index for all the faces send a request of the form: 
send full-index 

You may include several requests in a single piece of mail, but put each on a separate line. Faces are 
usually stored by their electronic mail addresses: e.g. rick@uunet.uu.net would be stored as 
uunet.uu.netlrick. To get it, you would send the command: 
send uunet.uu.net/rick 

uucp sites are stored in a domainish format: e.g. usenixUou would be stored as usenix.uucpllou . So, to get 
it, you would send the command: 

send usenix.uucp/lou 

Those faces that do not have an email address associated with them are stored in the directory 
no-email-address by their first_lastname. e.g.: 

send no-email-address/p_s_langston 

(see the full-index for the actual names). The format of the files is described in the file format. To get it 
send: 

send format 

To request programs send the command: 

echo send index from programs | mail uunet!faceserver 
To get a specific program: 

echo send WHATEVER from programs I mail uunet!faceserver 
Send the requests to "uunet!faceserver” even though replies appear to be coming from 
“uunet!faceserverd”. You’ll be talking to a program, so don’t expect it to understand much English. 


A picture file contains some or all of these information lines: 

FirstName: Random J. 

LastName: Attendee 
E-mail: rja@nullsys.uucp 
Telephone:1 800 555 1212 
Company: Computers R Us 
Addressl: 1234 Fifth Street 
Address2: MS 275W-137N 
CityStateZip: Gotham, UX 99999-0000 
Date: Jun 12, 1989 

PicData: (Actual data) width - height - bits/pixel 

Image: (Should be transformed to) width - height - bits/pixel 

(Blank line) 

Hexified picture in scanline order. 



Separated at Birth? 
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Selected “Faces” from Baltimore 



USENIX Weanie 



So Tired 



Abominable Hackcrman 



Dogs of USENIX 


Baghwan Bagman 



CyberPink Barry 




Beanheads of USENIX 


Fido 


Henry 
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USENIX Online Index 

What Is It: 

The USENIX online index is an electroni¬ 
cally available 

list of papers published by the USENIX Asso¬ 
ciation and related groups. The index is kept 
as a simple ASCII file, in refer/bib format, 
sorted by author. It contains information 
about papers published in USENIX and UNIX- 
related conference and workshop proceedings, 
newsletters, journals, and the like. 

In some cases, electronically readable ver¬ 
sions of full papers or abstracts are also avail¬ 
able. If a paper is available online, this is 
indicated in its index entry. 

The index is updated approximately 
monthly. 

How to Get the Index: 

The index is available online from uunet, 
either via a mail server or anonymous ftp. 
The index is about 200K, and available only in 
its entirety. To get it via electronic mail: 

echo send bibliography | \ 
mail uunet!Iibrary 

A (non-human) server will automatically break 
the index up into mailable chunks (if 
necessary), and return it to the sender of the 
mail. 

Or, the index can be retrieved via 
anonymous ftp to uunet.uu.net: 

ftp> get library/bibliography 

To get a help file: 

echo help | mail uunet!Iibrary 

To pick up the date the index was last 
updated: 

echo send date | mail uunet!Iibrary 

(Note - There is no person associated with 
“library-request” and it will never be read by 
human eyes.) 


Online Papers: 

We are actively soliciting the donation of 
electronic versions of papers to include in the 
library. If you have a paper you would like to 
donate, either with or without releasing 
copyright, contact the office for specific details. 
When the paper retrieval capability is fully 
functional, we will announce the procedures. 

Publications Indexed: 

Currently we have indexed all available 
issues of the following: 

USENIX: 

Conference proceedings 
Workshop proceedings 
Computing Systems Journal 
Newsletters (;login:) 

European UNIX User Group: 

Conference proceedings 
Newsletters 

Software Tools User Group: 

Conference proceedings 

Australian UNIX User Group: 

Newsletters 

The UNIX Review periodical is currently 
being indexed and will soon be available. 
Other sources (AFUU, GUUG, NZUSUGI, etc.) 
are being continually evaluated and will be 
included as deemed suitable. 

More Information: 

For additional information about the 
online index and library, and/or instructions 
for donating papers, contact: 

usenix!index (indexausenix.org) 

Or write to the USENIX Association. 
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Book Review 

Xlib Programming Manual 
(Volume One) 
by Adrian Nye 

(O’Reilly and Associates, Inc.) 611 pages 

Xlib Reference Manual (Volume 
Two) 

(O’Reilly and Associates, Inc.) 700 pages 

Reviewed by Marc Donner 

donner@ibm.com 

According to all the X gurus I know, one 
should never need to read or use books like 
these two. One is supposed to write X applica¬ 
tions using a toolkit (any of a number, includ¬ 
ing Xt from MIT, Xaw from CMU, and others) 
and never descend to the level of the X 
libraries. If this is the case, who might be 
customers for these two books? Toolkit writ¬ 
ers are the first who come to mind. Book 
reviewers come second. In a more serious 
vein, I suspect that the X application program¬ 
mer will not feel secure unless he (or she) has a 
copy of the contents of these two books at 
hand. 

The material in these books should be 
substantially the same as that in the Xlib 
documentation that comes with X11R3. I 
looked at a printed copy of the release docu¬ 
mentation to see what might make me want to 
spend money for thirteen hundred pages of 
documentation, when I could print fewer than 
three hundred on my local printer. 

The book is up-to-date on several minor 
matters of detail. For example, all atom 
names are now prefixed with XA_ and the 
books reflect this, though the free documenta¬ 
tion does not. I looked in the Xatoms.h file to 
see which was correct and it was the book. 
The man-page-like entries were adapted almost 
verbatim from the distribution, up to and 
including sentences ending with prepositions. 


On the other hand, the description included 
with each man page is much more detailed in 
the book and shows evidence of having been 
written by someone with a good understanding 
of English. Several improvements to the free 
man pages include reference to appropriate 
sections of volume one in the description, 
itemization of the error returns, and a listing 
of related functions. 

Volume one is full of friendly descriptive 
text about how things work and some things to 
watch out for, but it seems to be pitched a lit¬ 
tle too low. The cross referencing is rich, 
though it isn’t always clear that it is relevant. 
The exposition in volume one is based about 
some examples. The one pain is that the code 
is not easily available in machine-readable 
form. Perhaps it will make it to some future 
release of XI1, but for now it isn’t possible to 
play with the code without typing it in or 
sending $10 for a diskette. 

The great strength of volume two is the 
large quantity of cross referencing provided by 
the various appendices. Each appendix tries 
to organize some part of the vast X name 
space according to one principle. The first 
appendix provides groups of related functions. 
The third appendix does the same thing with 
macros. The fifth appendix provides a man 
page for each event, while the sixth appendix 
details all the data structures. The only extra 
thing I’d have asked for here is a cross refer¬ 
ence to the appropriate header file for most of 
the things named here (and in the man pages 
as well). Finding things in the X directories is 
always an adventure, even when you know 
their names. 

All in all, the books are well executed and 
moderately well written. The content seems 
complete and about as free of obvious errors 
as XI1 itself. The books are primarily aimed 
at application programmers, even though the 
X community is urging everyone to use toolk¬ 
its instead of writing on top of the library 
directly. I suspect that until a lot more work 
is finished it will be necessary for application 
programmers to use the library interface from 
time to time, so these books will be useful to 
them. 
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White Paper on System Administration for IEEE 1003.7 

Susanne W. Smith 

Windsound Consulting 

John S. Quarterman 

USENIX Association 


ABSTRACT: The new POSIX committee on System Administration, IEEE 1003.7, is attempting to 
standardize an area in which there is little prior art, and no generally accepted solutions to many of 
the known problems. It is a large area, and one that intersects with other areas such as networking 
(IEEE 1003.8) and application programming (IEEE 1003.2). Some of the most applicable prior art was 
not designed for operating system administration, but for network administration. Perhaps most 
importantly, there are two basic models for system administration. One must be chosen from the 
outset, and the choice will affect everything the committee does. 

The USENIX Association has coordinated the production of this White Paper to set forth the 
basic issues the committee must address, to recommend certain choices it will have to make, and to 
outline some of the existing solutions that must be considered. 


1* Introduction 

The role of the system administrator has 
evolved over the years. Where once an 
administrator was responsible for a single 
machine or machines from a single vendor 
there is now often a network of machines from 
different vendors. Both the homogeneous sin¬ 
gle machine case and the heterogeneous 
networked case must be addressed by the 
system administration committee in producing 
a standard. This paper offers a description of 
system administration, its component tasks, 
and its scope; it recommends a model upon 
which to build the standard; it presents an 
overview of some current system administra¬ 
tion practices; and it provides a reference list. 

2. The Basic Model 

The most basic choice for a system 
administration standard is between a single 
machine model and a model based on a net¬ 
work of machines. 

2.1 A Single Machine 

The results of 1003.7 will be applied to 
many machines that are not connected to any 
other machines, except perhaps by some 


indirect technique such as UUCP. The stan¬ 
dard must be applicable to such machines. 
For this purpose, it need only specify a com¬ 
mand interface and detail what the commands 
are supposed to accomplish. 

However, there is a problem with basing 
the standard on a single machine as a model, 
because such a standard will not adapt well to 
a network of machines. The traditional 
methods used for administration of a single 
machine are not readily extended for a 
networked environment. For example main¬ 
taining user information on a single machine 
requires modifications to the / etc/passwd file. 
In a networked environment this further 
requires maintaining the consistency of this 
file across many machines. 

2.2 A Network of Machines 

The number of machines connected to 
networks and the number of networks of com¬ 
puters have grown exponentially in the last 
several years. Many of us are accustomed to 
interacting with hundreds of computers on a 
local area network that is in turn connected to 
hundreds of thousands of other computers 
through wide area networks. 
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2.2.1 Remote Access 

Many machines do not even have local 
disks: files are kept on a central server, which 
is accessed over the network. There may be 
more than one server, and two machines may 
even act as servers for each other for different 
parts of their file system trees. 

2.2.2 Distribution 

Databases may not have a single location. 
The mapping between login names and login 
IDs may be distributed among several 
machines. The whole database may be dupli¬ 
cated for redundancy. Parts of it may be kept 
in different places, for local control. A tree 
structure may be used. 

2.2.3 Heterogeneity 

Networked environments tend to have 
machines with many different hardware types 
and many different variants of operating 
systems. One machine may have /etc/passwd 
and another may use a distributed database. 
The possible parameters to an operation may 
differ. Byte orders and word lengths vary. 

2.3 Specifications 

A single interface specification is not 
sufficient for a networking model of system 
administration. Three things are needed: 

2.3.1 Interface 

A specification of a programming interface 
is needed for a networked model, just as for a 
single machine model. Additional commands 
may be required for a networked model. But 
the specification of what the commands for the 
interface do has to be more complex for a 
networked model. 

2.3.2 Database 

Because of differences among machines in 
a heterogeneous network, such as varying byte 
orders, word lengths, and options supported, a 
generic specification of the information to be 
managed is needed. It is not practical to pro¬ 
vide specifications for every type of machine 
and software and translations between them, 
because the numbers of specifications needed 
would be very large. 


2.3.3 Operations 

Given the interface specification of a com¬ 
mand, and the database specification of the 
information it is to affect, a specification is 
also needed of how to communicate the 
necessary operation across the network. This 
should be done in a manner that is not specific 
to any of the underlying systems, but that can 
be translated into appropriate actions on any 
of them. 

2.4 Network Management Standards 

These issues and this kind of model have 
been addressed for the purpose of managing 
networks. It is possible that the work can be 
adapted and extended for use by 1003.7. Two 
components, a management station and a 
management agent, work together to perform 
network management functions in the follow¬ 
ing two protocols. The management station 
monitors and controls network elements. 
Management agents perform functions 
requested by the management station on the 
network element. 

2.4.1 CMIP 

The Common Management Information 
Protocol is the emerging ISO standard for net¬ 
work management. It uses a MIB (Manage¬ 
ment Information Base) and defines operations 
to be performed on it over a network. 

2.4.2 SNMP 

The Simple Network Management Pro¬ 
tocol is in use now with TCP/IP on NSFNET. 
It addresses many of the basic network 
management problems and presents at least 
preliminary solutions to them. It proves the 
concept of a MIB with operations to 
manipulate it over a network. 

2.4.3 ASN.l 

Abstract Syntax Notation 1 is the ISO 
standard for encoding of information at the 
presentation layer of the seven layer ISO net¬ 
working model. It is similar to Sun’s XDR 
(External Data Representation) or Apollo’s 
NIDL (Network Interface Definition Language) 
or NDR (Network Data Representation), but 
is more general than either. “ASN.l is useful 
for describing structures in a machine 
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independent fashion. Additionally, ASN.l 
definitions can be written which convey to the 
human reader the semantics of the objects they 
define.” 2 

Both CMIP and SNMP are written in terms 
of ASN.l. 

2.5 Scope 

The responsibilities of system administra¬ 
tors vary widely among installations. In some 
environments the tasks of the system adminis¬ 
trator are defined as “anything it takes to keep 
computing services available for the user com¬ 
munity.” This definition could encompass 
everything from hardware diagnostics to net¬ 
work management. In some situations the 
system administrator may be responsible for 
user support and consulting. In other situa¬ 
tions the tasks of the system administrator 
could be rigidly defined to only include pass¬ 
word file maintenance and backups. Because 
there is no commonly-accepted definition of 
the scope of system administration, the com¬ 
mittee needs to define which specific areas are 
included as the functions of a system adminis¬ 
trator. Scope and definitions are also required 
parts of an IEEE standard. These should be 
addressed before commands and facilities are 
defined. 

The committee should consider previous 
work in network management. The OSI model 
for network management consists of five func¬ 
tional areas: configuration management, per¬ 
formance management, fault management, 
accounting management, and security manage¬ 
ment. These functional areas map very well 
from network management to operating system 
management. 

2.5.1 Configuration Management 

Configuration management in the network 
sense is defined as “detection and control of 
the state of the network, both the logical and 
physical configurations of the network.” 1 
Configuration management in a system 
administration context would refer to the 
management of the information which defines 
a machine’s functions. Configuration informa¬ 
tion determines whether a machine is a file 
server or client, a timesharing service or single 
user, diskless or diskful. The configuration 


data identifies the location of other machines 
and services. 

2.5.2 Performance Management 

Performance management could be 
defined as the collection and analysis of infor¬ 
mation that determines a machine’s perfor¬ 
mance. Examples could be disk throughput, 
service access times, or cpu utilization. 

2.5.3 Fault Management 

Fault management is “the detection, isola¬ 
tion, and correction of abnormal operations in 
the network.” 1 For system administration this 
would be detection of a service’s failure, 
notification of the user community of failure, 
and the initiation of a backup service. 

2.5.4 Accounting Management 

Accounting management would be the 
management of the information required to 
determine the cost of using the system. This 
type of information is traditionally collected in 
units of disk storage blocks, cpu usage, and 
connect time. 

2.5.5 Security Management 

Security management is composed of the 
functions required to regulate access to system 
resources. User authentication, server 
verification, and security logs are functions of 
security management. 

2.6 Recommendations 

We strongly recommend the adoption of a 
network model. We also recommend that the 
committee focus on the entities to be managed 
and not the underlying transport protocol. 

2.6.1 Specifications 

Every command should be specified in 
terms of an interface, an information database, 
and operations to be performed over a net¬ 
work. Although the first of these alone would 
be sufficient in a single machine case, it is not 
adequate in a networked environment. A net¬ 
work model can be reduced to handle a single 
machine as a special case, but a single machine 
model cannot readily be expanded to support a 
networked environment. This is the main rea¬ 
son that a network model should be adopted 
instead of a single machine model. 
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2.6.2 Network Management 

The committee should examine the work 
done to date on SNMP and CMIP, and should 
follow the progress of the committees that are 
producing those protocols. The 1003.7 MIB 
should be written in ASN. 1. 

3. Prior Art 

We present here some examples of areas 
in which there is prior art that the committee 
should consider. This is not an exhaustive list 
of either the areas to be covered or the prior 
art in a specific area. There, are other such 
areas, and we encourage others to submit 
proposals to the committee outlining them. 

The examples are grouped according to 
the OSI model described above. Because 
system administration covers a broader area 
than network management the categories have 
been extended. Additional categories may be 
required to completely include all system 
administration functions. 

3.1 Configuration Management 

In addition to the description above, 
configuration management could include user 
configuration information. This would include 
the information required to describe a user 
and their environment (i.e. the location of 
their home directory). This area could also 
include queueing systems. 

3.1.1 /etc/passwd 

The simplest database of user information 
is /etc/passwd. It is a single file which con¬ 
tains information about each user, /etc/passwd 
contains a user’s login name, user-id, group id, 
encrypted password, optional full name and 
additional information, home directory loca¬ 
tion, and program to be executed upon suc¬ 
cessful completion of the login process. User 
information is added, changed, or deleted by 
using the command vipw or one of many avail¬ 
able shell scripts and programs. Access to the 
information is controlled by file permissions. 

This scheme works well in a single 
machine environment. This method requires 
each machine to have an /etc/passwd file. As 
the number of machines on a network and the 
number of users increases, maintaining the file 


entries on each individual machine becomes 
an overwhelming, if not impossible, task for 
the system administrator. Different methods 
have been proposed to handle the task of 
maintaining an /etc/passwd file on each 
machine in a network. 

3.1.2 Yellow Pages 

Yellow Pages (yp) is a distributed network 
lookup service. The Yellow Pages provide 
configuration information for a group of 
machines called a domain. A machine 
requesting information is a yp client and the 
machine providing the information is a yp 
server. 

The information for a particular domain 
is a set of maps. Commonly the /etc/passwd 
and /etc/hosts files are replaced by yp maps. 
However, ,yp is indifferent to the type of data 
in the maps. A master flat file resides on a 
master server machine. Updates to the master 
file are made there, dbm is used to transform 
the flat file into maps. The maps are then 
propagated to all slave server machines. The 
number of slave servers is dependent on net¬ 
work size and topology. A single machine may 
serve more than one domain. 

Once yp services are available (i.e. the 
maps have been made and the server machines 
configured) routines on the yp client machine 
must be modified to initiate yp requests rather 
than reading local files. Yp requests are 
remote procedure calls to a yp server. 

3.1.3 Moira 

“The purpose of Moira is to provide a sin¬ 
gle point of contact for authoritative informa r 
tion about resources and services in a distri¬ 
buted environment.” 3 Moira is used to store 
information about users, the location of net¬ 
work services, the information needed to 
create the configuration files for network 
servers, as well as other information. Updates 
to the database are made using an application 
interface which is based on curses. Validity 
checks are performed on data to be updated. 
Access to each object in the database is con¬ 
trolled by an access control list. Statistics are 
kept about who modified the object last. 

Network server configuration files are 
created from the Moira database and sent 
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periodically to the appropriate servers. This 
eliminates the need to modify configuration 
files on individual machines. The Hesiod (see 
below) database is also created from the infor¬ 
mation in the Moira database. 

3.1.4 Hesiod 

Hesiod provides a read only front end for 
user information and the location of network 
services. User information is extracted from 
the Moira database and formated into ASCII 
files in BIND-compatible resource record for¬ 
mat. Modifications have been made to BIND 
to accept and process Hesiod type queries. 

Hesiod is used by the login process to 
acquire user information. Note, however, that 
Hesiod does not authenticate the user. 
Authentication is performed by Kerberos. 
Hesiod is also used by Ipr to retrieve printer 
information traditionally stored in the 
/ etc/printcap file. 

3.1.5 Berkeley Print Spooling 

The Berkeley print spooling system was 
intended for use with network print services 
where printers are connected directly to the 
network or to the serial port of a host machine 
on the network. The command Ipr is used to 
start the printing process. Line printer 
daemons (Ipd) run on each machine in the net¬ 
work to control the spool area, queue, printing, 
and network transfers. 

Ipr looks up information for the requested 
printer in the / etc/printcap file. This file con¬ 
tains information about each printer, such as 
location, filters needed, header page format, 
etc. It determines how to print a file from this 
information. 

The Ipc command provides queue manage¬ 
ment functions. Ipc is used to restart and flush 
queues, abort jobs, and check the status of 
queues and printers. 

3.1.6 MDQS - Multiple Device Queueing 
System 

MDQS provides for local printer support, 
remote printer support, local and remote batch 
job scheduling, conversion of troff to device 
specific format, and sending graphics data to 
plotters. MDQS consists of a queue manage¬ 
ment daemon, a general-purpose spooler, a set 


of device specific despooled-data processing 
slaves, and utilities for setting form types, 
disabling service, viewing queues, etc. 

A queue/device mapping table contains 
the queue name, device name, and the com¬ 
mand to be executed as a slave process for the 
dequeued data. Remote printing and execu¬ 
tion are handled by having slave processes 
which respool the data into the remote MDQS 
queues. The mapping table provides the flexi¬ 
bility for multiple devices to process from the 
same queue or one device to process from 
multiple queues. If NFS (network file system) 
or some similar mechanism is used, a single 
spooling area and daemon with control files 
can reside on one machine. This eliminates 
the need for respooling data into remote 
queues and the overhead of maintaining a 
local spooling area, daemon, and control files. 
The remote devices simply process the queue 
from the remotely mounted file system. 

3.2 Security Management 

Personal computers can be protected by 
making the machine physically secure. In a 
timesharing environment the operating system 
is used to protect one user from another. In a 
networked environment there are three 
approaches to prevent unauthorized access to 
network services: rely on the host to authen¬ 
ticate the user and then trust the host; require 
the host to prove its identity and then trust the 
host as to who the user is; make the user prove 
who they are for each network service. 

3.2.1 Kerberos 

“In an open network computing environ¬ 
ment, a workstation cannot be trusted to iden¬ 
tify its users correctly to network services.” 4 
Therefore Kerberos uses the third approach to 
system security; make the user prove their 
identity for each network service. In order for 
a user to prove their identity, they must be 
authenticated by Kerberos, not the workstation 
they are using. Passwords are never sent over 
the network, but are used locally to decrypt the 
authentication message from Kerberos. To 
prevent unauthorized use the local workstation 
destroys the user’s password after using it to 
decrypt the initial Kerberos message. 
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Once a user has been authenticated they 
have the keys to request various network ser¬ 
vices. Different applications can choose 
different levels of protection. The first is 
authentication at initiation but subsequent 
messages are just accepted if from the same 
network address. The second is where each 
message is authenticated but the contents of 
the message are not encrypted. The third level 
of security is private messages where each 
message is authenticated and encrypted. 

The Kerberos database contains a name, 
private key, and expiration date for each entity 
that will use Kerberos services. The master 
Kerberos database is kept and modified on one 
machine. Slave servers have read only ver¬ 
sions of the database and provide read only 
types of services. Modification to the master 
database is accomplished by the administra¬ 
tion server (KDBM server). There are two 
parts to this service: a client which will run on 
any machine in the network and a server that 
must run on the machine which houses the 
master database. 

3.3 Accounting Management 

Accounting is the recording and reporting 
of resource usage. This information can then 
be used to determine appropriate charges for a 
user. 

3.3.1 Harvard Accounting System 

This system would track disk usage, cpu 
time, logins, connect time, printed pages, and 
budget on an account-by-account basis and 
charge the appropriate accounts. It was 
designed to run in a single machine environ¬ 
ment. 

3.4 Fault Management 

In order to restore service after a disk 
failure a sensible backup procedure needs to 
have been followed by the administrative staff. 
Basic commands to move data from one 
medium to another are described below. 

tar and cpio file archiving and data inter¬ 
change formats are the only backup formats 
specified in 1003.1. 


3.4.1 System V Interface Definition (SVID) 

3.4.1.1 volcopy 

The volcopy command will make a literal 
copy of a file system. Copies can be made to 
another disk location or to tape. 

3.4.2 SVID & Berkeley 

3.4.2.1 tar 

The tar command is used to create an 
archive file. Multiple files can be saved to and 
restored from a single tarfile. The tarfile can 
reside on various physical media, tar will read 
from standard input and write to standard 
output so that it can be part of a pipeline. 
This feature can be used for moving direc¬ 
tories. 

3.4.2.2 cpio 

cpio copies a list of files to or from a cpio 
archive file. Pathnames and status informa¬ 
tion are kept along with the files. 

3.4.3 Berkeley dump / rdump / restore / 
rrestore 

The dump and rdump commands will 
copy all files in a file system to backup media. 
The restore and rrestore commands will copy 
files stored via dump to a file system, rdump 
and rrestore provide the same functionality as 
dump and restore over a network. Remote 
dump devices are specified as a host-device 
combination. The dump command allows for 
different levels of backup. A level 0 dump 
copies every file in the file system. A level 5 
dump would copy every file that has been 
modified since the last dump of a lower level. 

3.5 Performance Management 

Performance management analyzes the 
output from system statistics to determine 
problem areas and develop solutions. 

3.5.1 Berkeley Performance Monitoring 
Commands 

The following commands are executable 
directly on each machine to report local status. 
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3.5.1.1 vmstat 

The vmstat command provides informa¬ 
tion on memory usage, process status, and disk 
utilization. 

3.5.1.2 iostat 

The iostat command reports statistics 
related to I/O operations. Both terminal and 
disk I/O are included. 

3.5.1.3 netstat 

The netstat command displays the 
contents of network-related data structures. 
Information is provided about established con¬ 
nections and gateways. 

4. Work in Progress 

4.1 OSFRFT 

The Open Software Foundation will be 
issuing a Request for Technology (RFT) for 
System Administration software from the 
Munich office sometime in August 1989. 

4.2 FDDI 

A group is forming to determine which 
variables are appropriate for inclusion in the 
MIB for FDDI. 

4.3 Network Management Language 

“NML is seen as a canonical interface 
between the network management application 
programmer and the MIXP (Management 
Information Exchange Protocol).” 5 It isolates 
the applications programmer from the specific 
MIXP being used. Extending this to system 
administration would enable the underlying 
protocol to be changed without the system 
administrator’s programming environment to 
be changed. 
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Report to EUUG and USENIX on 
ISO JTC1 SC22 WG15 (POSIX) Meeting 
May 1-3, 1989 

Dominic Dunlop 

The Standard Answer Ltd. 


Introduction 

This is the first of a series of reports which 
I shall be making on the activities of Working 
Group 15 of Subcommittee 22 of Technical 
Committee 1 of the International Standards 
Organisation (ISO TC1/SC22/WG15). It is this 
group which is taking the work of the Institute 
of Electrical and Electronic Engineers (IEEE) 
on POSIX, a portable operating system inter¬ 
face, from its current official status as an 
American national standard to its final goal as 
an international standard. I have been spon¬ 
sored by the European UNIX systems User 
Group (EUUG) and USENIX to attend the 
meetings of the working group on your behalf, 
representing your views and reporting back on 
developments which affect your interests. 

Meeting Report 

Hosted in Ottawa by the Standards Coun¬ 
cil of Canada, May’s three day meeting of ISO 
TCI / SC22 / WG15 was attended by five “tech¬ 
nical experts” (representatives) from the USA, 
three from the UK, two from Denmark, and 
one each from Canada, France, Japan, and the 
Netherlands. There were three “invited 
experts”: myself, invited by the UK delega¬ 
tion to represent the EUUG and USENIX; 
Shane McCarron, invited by the USA on 
behalf of UNIX International; and Mike Lam¬ 
bert of X/Open Company Ltd. 

Mike Lambert was invited by Jim Isaak, 
convener of the working group, to set out 
X/Open’s mission and its position in relation 
to ISO’s activities. It was clear that this was 
necessary as, in the responses to a previous 
ballot on the working group’s work-in-progress, 
several respondents effectively asked “Why are 
we doing this? Doesn’t it duplicate the work 
of X/Open?” What is more, the Comite 
Europen de Normalisation (CEN - European 
Committee for Standardisation) is in the 


process of voting on a proposal from West 
Germany that the whole of the X/Open Porta¬ 
bility Guide, Third Edition , 1988 (XPG3) 
should ♦become a “draft European Prestan¬ 
dard” - one step away from being a European 
standard. 

X/Open’s position is clear: “X/Open is 
not,” as the preface to each XPG volume 
states, “a standards-setting organisation.” 
Instead, X/Open is committed to align itself 
with international standards as soon as these 
are agreed, suggesting that its members adhere 
to other, less formal, national or de-facto stan¬ 
dards only when no international standard is 
in place. In order that national and interna¬ 
tional standards can be arrived at in a timely 
manner, X/Open fully endorses the activities 
of organisations such as the IEEE, ANSI, and 
ISO, and provides resources to aid in their 
activities, as it has done - and continues to do 
- in the case of the IEEE’s 1003 (POSIX) 
developments. Consequently, the Working 
Group considers that it is inappropriate for an 
international standards body such as CEN to 
align itself with the XPG; the XPG is not itself 
intended to be a formal standard, but rather a 
series of moving pointers to other standards. 
As such, it performs a valuable service to 
industry by indicating areas where more for¬ 
mal standardisation work should take place in 
the future. Each XPG pointer keeps moving 
until the area it addresses has become the sub¬ 
ject of an agreed international standard. It is 
unlikely that CEN would tolerate such moving 
pointers, and would effectively freeze the XPG 
in its current state. 

Another problem is that XPG3 specifies C, 
COBOL, and FORTRAN - languages covered by 
other European Standardisation efforts. It also 
calls out communications protocols, media for¬ 
mats, and a graphics interface (X) which may 
or may not overlap or conflict with other 
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standards. It is not clear that these matters 
were considered before CEN moved to a vote. 

Happily, well-defined mechanisms exist 
for communication between ISO and CEN, and 
“maximum alignment with ... ISO ... DP9945” 
is a requirement of the European 
Community’s “order form” to CEN requesting 
that a POSIX-based European Standard be pro¬ 
duced. The working group is using the chan¬ 
nels to suggest that DP9945, and, in the near 
future, the draft IEEE 1003.2 standard, replace 
XPG3 in their deliberations. 

C++ Standardisation 

The issue of C++ standardisation was 
raised in the working group, as there was a 
(rather vague) feeling that object-oriented 
facilities are essential for future developments 
in operating systems, user interfaces, com¬ 
munications systems, and the like. WG15’s 
parent, subcommittee 22, has responsibility for 
language standardisation. A resolution was 
drafted recommending that work be started on 
standardisation of an object-oriented program¬ 
ming language based on C. (The bulk of any 
such work would probably be given to ANSI, 
just like the work on C itself.) However, 
several valid objections resulted in the resolu¬ 
tion being dropped: 

• It is not clear whether the best basis for 
such a standard would be AT&T’s C++, 
Stepstone’s Objective C, or something 
else. (The issue is known to excite reli¬ 
gious fervour.) 

• It is not clear whether or not the language 
(whatever it is) should be constrained to 
be a superset of C. Such a constraint 
would be desirable from the point of view 
of compatibility, but might compromise 
the ideological soundness of the language. 
(Religion again.) 

• The business of WG22 is the definition of 
an operating system interface. It should 
not concern itself with the means of 
implementation of an operating system 
which presents that interface - even if 
almost everything that conforms to the 
definition happens to be written in one 
particular language - C. 


All this may seem to be somewhat arcane 
- distanced from reality. What it boils down 
to is that WG22 does not think it is time for 
international standardisation of an object- 
oriented C derivative. More work needs to be 
done by industry groupings and national stan¬ 
dards bodies - and more users need to vote 
with their feet - before the terms of reference 
for an international standard become clear. 

A Language-independent Definition of 
POSIX 

The working group discussed the path 
towards a language-independent definition of 
POSIX, an issue which took on added urgency 
because the working group’s decision was 
required in order that the IEEE could deter¬ 
mine the initial format of its 1003.4 standard 
(real-time extensions to 1003.1), which moves 
to ballot in January, 1990. Like IEEE 1003, 
WG15 intends that the standards it produces 
should ultimately be expressed in a form 
which is independent of any particular com¬ 
puter language. And also like 1003, WG22 is 
currently drafting standards in terms of the C 
language. Two questions arise: how indepen¬ 
dent, and how ultimate? 

IEEE 1003.1 is working towards removing 
C-language dependencies from Std. 1003.1- 
1988, but is stopping short of using a Formal 
Definition Language (FDL). While this 
precludes the automatic generation of test pro¬ 
cedures, which would be possible were a 
verifiable FDL used, it is do-able in the short 
term. Soon enough, in fact, to allow 1003.4 to 
go to ballot in a language independent form. 
If 1003.1 were to drop its work in favour of a 
FDL, results would be postponed for some 
years, and 1003.4 would have to be defined in 
terms of the C language, much to the distress 
of the Ada community. 

WG22 decided that use of a FDL was 
most appropriate to an international standard. 
Consequently, the group had to decide whether 
it wanted 

a. to ignore 1003.1’s work (which could 

result in 1003.1 dropping the activity); 

b. to recommend that 1003.1 adopt a FDL 

(with a resultant gross delay); or 
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c. to use 1003.1 ’s work as a basis for sub¬ 
sequent WG22 progress towards a formal 

description of POSIX interfaces. 

The last option was chosen, resulting in a 
resolution which exhorts 1003.1 to keep up the 
good work. Expect 1003.4 to be language- 
independent. 

For its part, WG22 is going to look into 
FDLs - a particularly esoteric subject - in 
more detail at its next meeting in Brussels in 
October. Ultimately, its standards will have 
three levels: 

1. Formal description (verifiable, but almost 
incomprehensible to mere mortals); 

2. Informal, but computer language- 
independent, commentary; and 

3. Series of language bindings, which may or 
may not implement the whole interface. (For 
example, a COBOL binding might well exclude 
the fork interface.) 

This should keep us busy well into the 
1990s. 

Security 

ISO, in order to exercise adequate control 
of activities dispersed both geographically and 
in time, tries to compartmentalize as much as 
possible, making sure that the responsibilities 
of each subcommittee and working group are 
very well defined. However, there are certain 
topics which just cannot be pushed into a sin¬ 
gle compartment: internationalisation is cer¬ 
tainly one, affecting as it does almost every 
aspect of information technology; security - an 
issue which currently has many people 
extremely worried - is probably another. 
Despite this, ISO TCI, having decided that the 
issue needs an identifiable home, may be con¬ 
vening a new working group - probably WG27 
- to handle all aspects of security. (There is 
mudj vagueness here: TCl’s mailing 

mechanism appears to have failed, with the 
result that nobody is sure exactly what will be 
voted on at its meeting in Paris later in May.) 

Of course, this has WG15 worried, both in 
its own right, and on behalf of other groups 
and subcommittees affected by issues of 
security. (Most notable among these is SC 18, 


which manages the burgeoning ISO protocol 
stack.) Consequently, a resolution has been 
forwarded to TCI via SC22 saying, in effect, 
“We’re in this together. Let’s work together.” 
The means of working together is a rapporteur 
group, a mechanism which exists to allow one 
group to monitor the activities of another. 
WG22 has such groups covering verification 
and internationalization as well as security. 

Application Environment Profiles 

Jim Isaak, convener of WG22, is much 
concerned with the issue of functional stan¬ 
dards for applications portability, or Applica¬ 
tion Environment Profiles (AEPs). Jim chairs 
IEEE 1003.0, which, in effect, is stocking the 
shelves of a standards supermarket from which 
users can pick the selection (or profile) needed 
to allow applications of a particular type to be 
realised in a portable manner. (X/Open, The 
Open Software Foundation, and more than a 
few governments are doing much the same sort 
of thing.) One example of such a profile might 
satisfy the needs of applications requiring 
distributed database services with reliable tran¬ 
saction processing and high security. 

Already, the IEEE has working groups 
which are defining AEPs: 1003.10 for super- 
computing and 1003.11 for transaction pro¬ 
cessing, and Jim is engaged in selling the idea 
to ISO. Again, there are two questions: “Are 
you interested?” and “If so, what profiles do 
you want to specify?” 

It is early yet: the issue is to be raised at 
Technical Study Group l’s (TSGl’s) meeting in 
Essen, Germany, in September. (TSGs are 
another ISO mechanism which is brought into 
play to handle interdisciplinary issues.) TSG1 
is developing a framework for application por¬ 
tability, so it should consider AEPs worth 
adopting. In the meantime, feedback concern¬ 
ing useful and desirable AEPs is solicited by 
IEEE 1003.0. 

Adoption of IEEE’s Draft 1003.2 Standard 

Finally, WG15 has decided that it is time 
to adopt IEEE’s draft 1003.2 standard. Shell 
and Application Utility Interface for Computer 
Operating System Environments as the basis 
for a corresponding international standard. A 
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little procedural gymnastics is involved: the 
first SC22 meeting that could authorise such an 
adoption is in September, and it is not clear 
which draft of 1003.2 will be current at that 
time: if things go badly it could be draft 8; if 
to plan, draft 9. Also, draft international stan¬ 
dard 9945, which corresponds to IEEE 1003.1, 
must be renamed to 9945.1, allowing 1003.2 to 
form the basis of 9943.2. It took three 
separate resolutions to put this particular show 
on the road! 

Those, then, are the issues I consider 
important to members of EUUG and USENIX. 


Beyond them, there was much procedural stuff 
- more, for example, than at an IEEE meeting, 
even though WG22 is apparently quite infor¬ 
mal by ISO standards. 

Your comments are welcome; email them 
to domo@sphinx.co.uk. 


Comments Please 

We would like to know if you find the 
previous reports useful. Please send your com¬ 
ments to the editor ( ellie@usenix.org). 


Summary of the Board of Directors’ Meeting 
Short Hills, NJ, 17-18 April 1989 


Attendance 

Stephen C. Johnson, Rob Kolstad, Marshall 
Kirk McKusick, Sharon Murrel, Michael D. 
O’Dell, Alan G. Nemeth, John S. Quarterman, 
Deborah K. Scherrer. 

Judith F. DesHarnais, John L. Donnelly, Neil 
P. Groundwater, Elbe Young. 

Software Management Workshop Report 

Scherrer reported that there were 80 atten¬ 
dees, the technical content of the papers was 
satisfactory, and the overall evaluation by the 
attendees was good. 

Baltimore Conference 

Program. Groundwater stated that 60 submis¬ 
sions were received and 22 papers had been 
accepted. The ACM has asked to have 
abstracts of the papers. Quarterman requested 
that problems with papers appearing elsewhere 
be relayed to program chairs. 


Exhibits. Donnelly discussed his revised pro¬ 
jected finances. Kolstad asked for a discussion 
regarding the future of exhibits - will we sell 
less booth space. Donnelly stated that sales in 
Baltimore should match San Francisco, tha t 
the vendors think we’re important, and that 
they are concerned about location. Future site 
discussions should take into account having 
the site in a more “technical region” of the 
country. 

Tutorials. There are 15 scheduled per day. 
There was general consensus that the tutorial 
program is driving the conferences. Student 
discounts have been instituted and are being 
advertised. 

FaceSaver Proposal 

The FaceSaver service proposed for Bal¬ 
timore would capture new and revised faces to 
update the UUNET-maintained database, and 
not produce an attendee list as in the past. 
There was general agreement that it is a 
benefit to the membership and draws people 
into the exhibits. It was agreed to allocate 
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$12,500 to the FaceSaver proposal for the Bal¬ 
timore conference. Passed: 5 in favor, 1 
opposed, 2 abstained. 

San Diego Report 

It was reported that attendance at tutorials 
was high, and that the conference worked well 
without UniForum. There was concern that 
some future sites do not have as much tutorial 
space. While there were some comments from 
attendees about the absence of exhibits, there 
was overall enthusiasm for the box lunches 
and warm location. 

Washington D.C. ’90 

Scherrer reported that the program com¬ 
mittee has been formed. There was a lengthy 
discussion on how program chairs get their 
papers, the problems of having quality papers, 
the time constraints with having full papers vs. 
extended abstracts, and the Board’s role in 
providing guidelines to chairs. It was agreed 
that the type of papers needs to be decided 
beforehand and the chair notified. 

A committee was struck to study the 
problem and make proposals regarding 
abstracts vs. full papers and report to the 
Board at the next meeting. 

USENIX Room at UniForum in D.C. 

Because of the problems with location and 
cost it was decided that we will not have a 
USENIX room at the 1990 UniForum in D.C. 

Long Range Conferences 

1993 Winter Conference. DesHamais reported 
on three potential sites. The Board recom¬ 
mended that she pursue San Diego and Dis¬ 
neyland and choose between the two. 

1993 Summer Conference. The Board recom¬ 
mended that we sign a contract with Cincin¬ 
nati. 


problems with not getting all the papers from 
the Chair. 

Systems Administration III: Kolstad reported 
that we’re trying an experiment by offering two 
tutorials (by Nemeth and Kolstad) the day 
before the actual workshop. Standard tutorial 
rates will apply and he estimated that 50 peo¬ 
ple may attend each. 

Distributed Systems: Kolstad reported that the 
paperwork from the other sponsors would be 
forthcoming. The co-chairs are very active 
and seem to have things well under control. 

C++ '90: Jim Waldo of Apollo has accepted 
the chair. 

Since there were very few responses to the 
posting on the net for future workshop topics, 
it was agreed that individual Board members 
should actively search for future topics. 

Quarterman and Kolstad will look into a 
joint workshop with EUUG on Systems 
Administration. 


Future Conference Chairs 

McKusick was asked to invite Allman to 
be the ’92 San Francisco chair; Johnson was 
asked to contact Mashey about his plans for 
Anaheim in ’90; Quarterman was asked to 
offer Grob / Shore Dallas in ’91; O’Dell was 
asked to offer Adams San Antonio in ’92; 
Scherrer was offered (and she accepted) Nash¬ 
ville ’91. 


The following appointments for Board 
liaisons were made: 


Anaheim ’90 
Dallas ’91 
Nashville ’91 
San Francisco ’92 
San Antonio ’92 


Johnson 

Quarterman 

Nemeth 

McKusick 

O’Dell 


Alix Vasilatos was appointed Informal 
Programming Chair for Baltimore. 


Future Workshops 

O’Dell suggested that we make sure that 
either a Board member or staff person from 
the Executive office attend each workshop. 

Transaction Processing: Murrel reported that 
everything was on track, and that she would be 
attending part of it. Young mentioned 


Database Report and Conference Office’s 
Machine 

O’Dell reported on the committee’s meet¬ 
ing in Berkeley, where a dataflow model for all 
three offices was discussed. O’Dell said there 
are two problems - the long term problem of 
the database and the short term one of the 
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conference office’s machine. It was decided to 
deal with the latter immediately and to 
authorize $30,000 for a machine for the confer¬ 
ence office and that the database committee 
authorize these expenditures. 

Executive Director 

It was moved that Ellie Young be 
appointed Executive Director. Passed 
unanimously. 

High School Computing Funding 

It was approved unanimously to authorize 
$3,000 to fund Don Piele’s International Com¬ 
puter Problem Solving Contest. 

Standards 

Quarterman reported on the negotiations 
in Brussels between USENIX and EUUG 
regarding a joint representative to the ISO 
Working Group 15 POSIX committee. The 
two groups have hired Dominic Dunlop to be 
the representative. Quarterman was thanked 
by the Board. He also reported that USENIX 
is coordinating a White Paper on system 
administration for IEEE 1003.7, a new stan¬ 
dards committee in this area. 

Quarterman announced that McCarron 
would not be able to edit USENIX Standards 
Watchdog committee reports. There was 
discussion about making these reports into 
another publication. The Board, however, 
agreed that we should continue to publish 
these reports in ;login: and that Quarterman 
should hire someone else to do the reports. 

Legal Business 

In a letter from our attorney Dan Appel- 
man, the Board was advised to amend the 
corporation’s Certificate of Incorporation to 
limit the personal liability of its directors, and 
the Board did so. 

UUNET Report 

O’Dell had an updated version of 
UUNET’s finances. He reported that they have 
secured a line of credit, moved into new 
offices, and Rick Adams is now working full 
time as UUNET’s technical director. 


Relationship with EUUG and European 
National Groups 

Murrel, as the USENIX representative at 
the EUUG meeting in Brussels, gave a report. 

EUUG-Publications. Murrel expressed EUUG’s 
concern about the financial arrangement with 
USENIX for publications and the confusion 
about the initial arrangements. Young was 
instructed to work with EUUG on this and that 
future sales of publications would be 
coordinated with Philip Peake of the EUUG. 

Relationship with EUUG and the European 
National Groups. Murrel reported that while 
EUUG encourages all informal contacts 
between user groups, they would like to be the 
sole contact for EUUG and their national 
group members for negotiations leading to 
reciprocal agreements and purchases of ser¬ 
vices. There was general agreement that such 
a policy would be impossible since any 
USENIX member can order any quantity of 
our publications. 

Nemeth and Johnson suggested an 
exchange of publications with JUS so that we 
can abstract and index them. 

Proposal for Second UNIX on 
Supercomputers Workshop 

Lori Grab’s proposal that USENIX sponsor 
a second UNIX on Supercomputers workshop 
in early Fall of 1990 was approved. 

Publications and Membership 

Manuals. Young reported that while customer 
service from Howard Press has been poor in 
the past, she had met with them to relay our 
concerns as well as to check the inventory. It 
was recommended that we advertise the manu¬ 
als as “final printing” and push their sales at 
the conferences. 

Reprinting Proceedings. Young reported that 
after three postings on the net, the number of 
responses was still too little to warrant reprint¬ 
ing. We will offer out-of-print proceedings at 
our cost to reproduce them on a per request 
basis. 

Executive Office Report. Young went over the 
report. Total membership as of 4/1/89 was 
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2,712, up 30% from figures of the previous 
year. 

Budget 

There was a discussion regarding future 
costs for the journal. Young reported that the 
contract with UC Press calls for fees to be 
somewhat lower over the next two years, and 
with more library subscriptions our fees would 
be reduced even further. 

The Board was satisfied with Young’s 
efforts to provide a cash flow model for all 
three offices. There were some format sugges¬ 
tions for the reporting of membership services, 
and suggestions for other models to enable the 
Board to plan for future growth, projects, and 
have a better understanding of what has hap¬ 
pened in the past. 

It was decided to pay off the First Inter¬ 
state Bank loan for the Sequent machine and 
make arrangements with UUNET for a 
schedule of payments. 

Membership Fees / Dues Proposal 

There was discussion regarding Young’s 
proposal sheets. The general feeling of the 
Board was that the Association can continue to 
depend on the conference surplus to fund 
membership benefits. It was passed 
unanimously that the 1990 membership dues 
remain: 


Student: 

$15 

Individual: 

$40 

Educational: 

$125 

Corporate: 

$275 

Supporting: 

$1,000 


It was also approved that a subscription to 
the proceedings be included as a benefit to all 
institutional members as soon as possible. 

Election Subcommittee Proposal 

Murrel, speaking for the election subcom¬ 
mittee, proposed a Bylaw change to limit the 
number of consecutive terms for board 
members. The following wording change to 
the Bylaws was approved: 

Replace in section 4.2: 

Any eligible person may be reelected as an 
officer or director one or more times. 

with 

Any eligible person may be reelected as an 
officer or director one or more times, but 
may not be elected to more than four terms 
in succession. 

And that this Bylaw change will take effect 
after the next election, on July 1, 1990. 

-EY 
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UUNET Source Archives on Tape 

By popular demand, UUNET Communica¬ 
tions Services is making its collection of freely 
redistributable UNIX source archives available 
on tape to any interested parties. 

UUNET has over 500 megabytes of source 
archives on line for UUNET subscribers to 
access. These archives are now available to 
anyone. They are distributed on two 6250 bpi 
W tapes or FIVE W' cartridge tapes (QIC-24, 
Archive 60 megabyte tapes, i.e., Sun compati¬ 
ble). All files on the tape are compressed 
(except the compress program itself) to save 
space. The all inclusive cost of these tapes 
with prepayment is $200 for the Vi" tapes or 
$350 for the Vi" tapes. If you require us to 
process a purchase order or to invoice you, 
add $50 for processing costs (i.e., $250 for the 
Vi" tapes or $400 for the Vi" tapes). 

All sources are the latest available versions 
at the time the tape is written. Included on 
the tape are the MIT X Window System, Ver¬ 
sion 11 Release 3 plus fixes and lots of contri¬ 
buted software (110 megabytes); the complete 
comp.sources.unix archive (56 megabytes)*; the 
TgX text processing system (46 megabytes); all 
available GNU software (35 megabytes); the 
complete comp.sources.games archive (20 
megabytes); the freely redistributable software 
from the 4.3BSD-Tahoe & Networking releases 
of Berkeley UNIX (17 megabytes); various net¬ 
working related programs (30 megabytes); all 
the Internet RFCs (10 megabytes); the USENIX 
Facesaver data (60 megabytes); the 
comp.std.unix standards archives (10 mega¬ 
bytes); and lots more. 

To obtain the tape distribution or for 
further information contact: 

UUNET Communications Services 
3110 Fairview Park Drive, Suite 570 
Falls Church, VA 22042 

+ 1 703 876 5050 (voice) 

+1 703 876 5059 (fax) 
uunet@uunet.uu.net 


USENIX Software Distribution 
Tape 

The 1989 USENIX software tape (the final 
USENIX source distribution) contains software 
collected for USENIX by Plus Five of St. 
Louis. It has just been mailed to all institu¬ 
tional and supporting members of the Associa¬ 
tion. The tape is in tar format at 6250 bpi. 

Individual members of USENIX who wish 
to obtain a copy of the tape may request it 
from the Association office. The price is $60 
(includes domestic postage, foreign individuals 
will be billed for the additional postage). It 
requires no AT&T nor UC license. You will be 
sent a requestor “Tape Release Form” which 
should be returned to the Association. Check, 
purchase orders, or payment by VISA/MC are 
accepted. (For charge orders please include 
card number, expiration date, and your signa¬ 
ture.) Please allow 2 weeks for receipt of your 
order. 


Scholarship Winner 

The Association is pleased to announce 
that James N. Griffioen is the recipient of the 
1989-90 USENIX Scholarship. Griffioen is a 
Ph.D. student studying virtual memory operat¬ 
ing systems at Purdue University. 


Executive Office Staff 

Andrea Galleni has been hired as the 
administrative assistant for the Executive 
office. Andrea has been working part time for 
the Association during the past six months and 
many of you have met her at our past two 
conferences. She will assist the executive 
director in bookkeeping, publications, and the 
in the day-to-day business of running the 
Berkeley office. 
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CONFERENCE & WORKSHOP PROCEEDINGS 

Add'l 

Unit Foreign 

Qtv Proceeding Price Total Postage 

Total 


Baltimore Conference 

June '89 

$20 

$ 

$15 

$ 


UNIX Transaction Processing Workshop 

May '89 

12 

$__ 

8 

$ 


Software Management Workshop 

Apr. '89 

20 

$ 

15 

$ 


San Diego Conference 

Feb. '89 

30 

$ 

20 

$ 


C++ Conference 

Oct. '88 

30 

$ 

20 

$ 


UNIX and Supercomputers Workshop 

Sept. '88 

20 

$ . 

15 

$ 


C++ Workshop 

Nov. '87 

30 

$ 

20 

$ 


Graphics Workshop IV 

Oct. '87 

10 

$ 

15 

$ 


Washington DC Conference 

Jan. '87 

10 

$ 

20 

$. . 

— 

Graphics Workshop III 

Dec. '86 

10 

$ 

15 

$ 


Total price of Proceedings 
Calif, residents only add applicable sales tax 
Total foreign postage 

Total enclosed $. 


* Discounts are available for bulk orders. Please inquire. 


PAYMENT OPTIONS 

Q Check enclosed payable to USENIX Association. □ Purchase order enclosed. 

| Please charge my: Q] Visa Q MasterCard 

Account#________ Exp.Date __ 

Signature____ 

Overseas? Please make your payment in U.S. currency by one of the following: 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 

* Check - issued by a local branch of a U.S. Bank 

5/89 



Shipping Information 

Orders to U.S. and Canada are shipped via printed matter. Please allow 2 weeks for delivery. Foreign orders are 
shipped via air printed matter. Please allow 10-14 days for delivery. Shipment by UPS, first class, or airmail is 
available upon request. 

Ship to:_Please mail this order form to: USENIX Association 

2560 Ninth Street 

______ Suite 215 

__ Berkeley, CA 94710 
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CONFERENCE & WORKSHOP PROCEEDINGS 

Please enter my one-year subscription to the 1989 USENIX Conference & Workshop Proceedings, 
which include: 

San Diego Conference - February 1989 
Software Management Workshop - April 1989 
UNIX Transaction Processing Workshop - May 1989 
Baltimore Conference - June 1989 

Large Systems Administration Workshop - September 1989 
Distributed Systems Workshop - October 1989 
Graphics Workshop V - November 1989 

COST: $100.00 

Outside U.S.A. and Canada? Add $30 for surface postage. 


PAYMENT OPTIONS 

□ Check enclosed payable to USENIX Association. 
I I Please charge my: Q Visa Q MasterCard 

Account # 


Signature ________ 

Overseas? Please make your payment in U.S. currency by one of the following: 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 

* Check - issued by a local branch of a U.S. Bank 


I | Purchase order enclosed. 



Exp.Date 


Name 

Address ____ 

City___ State/Country_Zip/Postal Code 


Please mail this order form to: USENIX Association 

2560 Ninth Street 
Suite 215 

Berkeley, CA 94710 
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Local User Groups 

The Association will support local user groups by doing an initial mailing to assist the formation 
of a new group and publishing information on local groups in ;login At least one member of the 
group must be a current member of the Association. Send additions and corrections to usenixHogin . 


CA - Fresno: the Central California UNIX Users 
Group consists of a wwcp-based electronic mailing 
list to which members may post questions or infor¬ 
mation. For connection information: 

Educational and governmental institutions: 

Brent Auemheimer (209) 294-4373 

brent@CSUFresno.edu or csufreslbrent 

Commercial institutions or individuals: 

Gordon Crumal (209) 875-8755 

csufreslgordon (209) 298-8393 


CA - Los Angeles: the Los Angeles UNIX Group 
meets on the 3 rd Thursday of each month in 
Redondo Beach. 

Drew Bullard 
ucb vax! trwrb Ibullard 

(213) 535-1980 

Marc Ries 

{decvax,sdcrdcf} !trwrb!ries 

(213) 535-1980 

CO - Boulder: the Front Range UNIX Users Group 
meets monthly at different sites. 

Steve Gaede 

NBI, Inc. 

P.O. Box 9001 

Boulder, CO 80301 

{boulder,hao}!nbires!gaede 

(303) 938-2985 

FL - Coral Springs: 


S. Shaw McQuinn 

8557 W. Sample Road 

Coral Springs, FL 33065 

(305) 344-8686 

FL - Jacksonville/Northeast: 
sonville (uujax) meets the 
month. 

UNIX Users of Jack- 
2 nd Thursday of each 

Tom Blakely 
uflorida!unf7!tfb 

(904) 646-2820 

Emilie Olsen 

(904) 390-3621 


FL - Melbourne: the Space Coast UNIX Users 
Group meets at 8pm on the 3 rd Wednesday of each 
month at the Florida Institute of Technology. 

Bill Davis (407) 242-4449 

bill@ccd.harris.com 


FL - Orlando: the Central Florida UNIX Users 
Group meets the 3 rd Thursday of each month. 

Mike Geldner (305) 862-0949 

codas! sunfla! mike 

Ben Goldfarb (305) 275-2790 

goldfarb@hcx9. ucf. edu 

Mikel Manitius (305) 869-2462 

{codas,attmail) Imikel 


FL - Tampa Bay: the Tampa UNIX Users Group 
meets the 1 st Thursday of each month in Largo. 

Bill Hargen (813) 530-8655 

uunetlpdnihargen 

George W. Leach (813) 530-2376 

uunet!pdn!reggie 


GA - Atlanta: meets on the l sl Monday of each 
month in White Hall, Emory University. 

Atlanta UNIX Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 

Marc Merlin (404) 442-4772 

Mark Landry (404) 365-8108 


MI - Detroit/Ann Arbor: The SouthEastem 

Michigan Sun Local Users Group meets jointly with 
the Nameless UNIX Group on the 2 nd Thursday of 
each month in Ann Arbor. 

Steve Simmons 
scs@lokkur.dexter.mi.us 

K. Richard McGill 
rich@sendai.ann-arbor.mi.us 

Bill Bulley 
web@applga. uucp 


MI - Detroit/Ann Arbor: dinner meetings the 1 st 
Wednesday of each month. 

Linda Mason (313) 855-4220 

michigan!/usr/group 

P.O. Box 189602 

Farmington Hills, MI 48018-9602 


home: (313) 426-8981 
office: (313) 769-4086 
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MN - Minneapolis/St. Paul: meets the l sl Wednes¬ 
day of each month. 

UNIX Users of Minnesota 
17130 Jordan Court 
Lakeville, MN 55044 


Robert A. Monio 
pnessutt@nis.mn.org 

(612) 895-7007 

MO - St. Louis: 


St. Louis UNIX Users Group 

Plus Five Computer Services 

765 Westwood, 10A 

Clayton, MO 63105 


Eric Kiebler 
plus5!sluug 

(314) 725-9492 

NE - Omaha: meets on the 2 nd Thursday of each 
month. 

/usr/group nebraska 

P.O. Box 44112 

Omaha, NE 68144 

Kent Landfield 
kent@ugn.uucp 

(402) 291-8300 

New England - Northern: meets 

different sites. 

monthly at 

Emily Bryant 

Kiewit Computation Center 
Dartmouth College 

Hanover, NH 03755 

(603) 646-2999 

David Marston 

Daniel Webster College 

University Drive 

Nashua, NH 03063 

(603) 883-3556 

decvax!dartvax!nneuug-contact 


NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Pat Parseghian 

Dept, of Computer Science 

Princeton University 

Princeton, NJ 08544 

(609) 452-6261 

pep@Princeton. EDU 


NY - New York City: 

Unigroup of New York 

G.P.O. Box 1931 

New York, NY 10116 


Ed Taylor 

{attunix,phi!abs)!pencom!taylor 

(212) 513-7777 


New Zealand: 

New Zealand UNIX Systems User Group 
P.O. Box 13056 
University of Waikato 
Hamilton, New Zealand 


OK - Tulsa: 

Pete Rourke 
$USR 

7340 East 25 lh Place 
Tulsa, OK 74129 


PA - Philadelphia: the UNIX SIG of the Philadel¬ 
phia Area Computer Society (PACS) meets the 
morning of the 3rd Saturday of each month at the 
Holroyd Science Building, LaSalle University. 

G. Baun, UNIX SIG 
c/o PACS 
Box 312 

La Salle University 
Philadelphia, PA 19141 

rutgers! {bpa,cbmvax}! 

t emvaxlpacsbb! {gbaun, whutchi} 


TX - Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
Seny Systems, Inc. 

5327 N. Central, #320 
Dallas, TX 75205 

Jim Hummel (214) 522-2324 


TX - San Antonio: the San Antonio UNIX Users 
(SATUU) meets the 3 rd Thursday of each month. 

Jeff Mason (512) 494-9336 

Hewlett Packard 

14100 San Pedro 

San Antonio, TX 78232 

gatech!petro!hpsatb!jeff 


WA - Seattle: meets monthly. 

Bill Campbell (206) 232-4164 

Seattle UNIX Group Membership Information 
6641 East Mercer Way 
Mercer Island, WA 98040 

u w-bea ver! tikal! cameo! bill 


Washington, D.C.: meets the l sl Tuesday of each 
month. 

Washington Area UNIX Users Group 
2070 Chain Bridge Road, Suite 333 
Vienna, VA 22180 


Samuel Samalin (703) 448-1908 
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USENIX Association 

2560 Ninth Street, Suite 215 
Berkeley, CA 94710 


First Class Mail 


FIRST CLASS MAIL 
U.S. POSTAGE PAID 
Hayward, CA 
Permit No. 2 


New Conference Sessions 
Conference and Workshop Announcements 

Facesaver 
Standards Reports 
USENIX Online Index 
Book Review - Xlib Manuals 

Change of Address Form 

Please fill out and send the following form through the U.S. mail to the Association Office at the address above. 

Name:___Member #:_ 

OLD:_NEW:_ 


Phone: 

UUCP'. . 



